x-wing: Make X25519 non-contributory behaviour configurable - #369
Conversation
| /// [RFC 7748]: https://www.rfc-editor.org/info/rfc7748/#section-5 | ||
| /// [specifies]: https://www.rfc-editor.org/info/rfc7748/#section-6.1 | ||
| /// [CFRG have decided]: https://mailarchive.ietf.org/arch/msg/cfrg/v9fEHQj3QTUpdu72AzjyyrY4j2g/ | ||
| pub fn reject_x25519_non_contributory_behaviour(self) -> Self { |
There was a problem hiding this comment.
I made this an extra method and didn't change the default behaviour, in order to make this a non-breaking change. But then I remembered that changing from kem::Decapsulate to kem::TryDecapsulate is breaking anyway, so preserving behaviour is not technically necessary as long as we provide a way to reach either state.
6f791f0 to
cfefc89
Compare
Until the IETF RFC is published selecting a specific behaviour, we support both. Closes RustCrypto#364.
cfefc89 to
faabbc9
Compare
|
My personal inclination would just be to always reject, particularly if we switch to implementing I would also suggest against adding new methods to the public API, at least if their utility would be eliminated by a future change to the RFC. |
|
My 2c: it is odd to me to make |
|
@rozbb that's an interesting direction and could be done in a purely additive manner, then when the RFC is clarified we can remove one and keep the other |
3 participants
Until the IETF RFC is published selecting a specific behaviour, we support both.
Closes #364.